_______________________________________________________
May 1994
Author: Rehan Syed
Gupta Corporation
1060 Marsh Road
Menlo Park, CA 94025
April 1994
All trademarks, trade names and product names are registered trademarks or trademarks of their respective holders.
Copyright 1994, Gupta Corporation.
All rights reserved.
Information in this document may change without notice.
___________________________________________
As the business application development industry has progressed from low level programming techniques to higher level fourth generation languages (4GLs), developers have traded-off performance for greater productivity. Although this approach is acceptable for small and simple applications, the performance penalty is unacceptable for larger applications. As organizations attempt to build large scale, mission-critical applications using 4GL-based client/server technology, it is imperative that they find a development solution that delivers high productivity with high performance.
Since 1984, Gupta has focused on providing powerful tools for large-scale application development. Now Gupta has taken the lead in addressing the important issue of client/server performance. For the first time, developers can enjoy the productivity of a leading visual client/server development environment with the performance of a third-generation language. The "SQLWindows Compiler" is now available to marry the high productivity of SQLWindows with the fast performance of the C language. It enhances client/server performance by converting SQLWindows code into very fast C code which can be directly executed without additional modifications. Since this technology assumes no knowledge of C programming, it can be used by all 4GL developers without additional training. It is fast and easy.
In summary, the SQLWindows Compiler represents ground-breaking new technology to enhance the performance of your client/server applications. Client/server technology is now ready to be used for real-world, mission-critical application development.
___________________________________________
Since the dawn of business computing, application developers have progressed from lower level programming techniques to higher level languages. From machine language coding we progressed to assembly language programming and increased productivity. Next, we invented even higher level "third-generation" languages (3GLs) like COBOL, and later C, to minimize the tedium of assembly programming. A "compiler" program converts the 3GL code into assembly language which then gets "linked" into an "executable"which the CPU can understand. 3GLs offer much greater productivity but lower performance than assembly language. However, since hardware costs have fallen while machine speeds have risen, the use of 3GLs rather than assembly language, has become worthwhile. Today almost no business application developers write assembly code.
In the 1980s, 4GLs achieved wide popularity for providing much higher productivity levels than 3GLs because they required less code to be written but, again, at the expense of performance. Since hardware costs continue to fall and machine speeds continue to rise, many developers are abandoning 3GLs for new application development and instead using highly productive 4GLs like SQLWindows. A day will no doubt come when developers will completely abandon the use of 3GLs in lieu of 4GLs, just as 3GLs have supplanted assembly language.
3GLs became widespread because compilers readily translated them into assembly code. Therefore, they provided higher productivity without sacrificing too much performance. However, no parallel technology exists for 4GLs. Today, 4GLs are executed not by converting them into 3GL code but by converting them into a proprietary format called pseudo-code or "p-code". The p-code instructions are then executed by an "interpreter" supplied by the 4GL vendor.
This approach of generating p-code rather than assembly code is inherently slow because the interpreter needs to simulate p-code execution at run-time. It follows that if 4GLs were to be converted to assembly level instructions rather than p-code, 4GL applications would run much faster. This is in fact possible, as described later in this white paper.
Over the last decade, corporate and individual developers have agreed that fourth-generation languages (4GLs), like SQLWindows, offer developers an order of magnitude greater productivity than third-generation languages (3GLs) like C. Given that, why do developers still use 3GLs today?
One reason is the greater programmatic control provided by 3GLs. Some tasks that are difficult or impossible to accomplish with 4GLs are more easily done with 3GLs. For example, if you want to write a program that performs sophisticated scientific computations, a 3GL is recommended.
Another reason is the superior performance provided by 3GLs. Since 3GLs are "compiled" into assembly language, 3GL applications execute faster, often an order of magnitude faster than 4GLs.
At present, the only mechanism available to developers to harness the greater productivity of 4GLs with the superior performance of 3GLs is to write an application that consists of both 4GL and 3GL code and link the two portions together. While this approach delivers greater productivity than using 3GLs alone, and greater performance than using 4GLs alone, it does not maximize both benefits. Another shortcoming of this approach is that the developer needs to be familiar with coding in both the 4GL and 3GL, which is often not the case.
This situation poses two key questions to vendors of 4GL development tools:
Gupta believes that the above issues of performance, productivity and skill can be resolved by providing a tool that takes 4GL code, i.e. SQLWindows code, and converts it into 3GL code, which in turn is converted into assembly language. This is accomplished using ground-breaking new technology called the "SQLWindows Compiler". The SQLWindows Compiler is an integral component of SQLWindows 5.0. It is the first tool which allows conversion of popular 4GL code into fast 3GL code.
One of the fastest 3GLs available is C, therefore this paper will focus on C generation. Once C code is generated by the SQLWindows Compiler, it is compiled into an executable using a C compiler from Microsoft, without additional development in C. This approach allows developers to work entirely in a 4GL yet achieve the performance benefits of a 3GL.
Thus, conversion of 4GL code into C code ensures that the application executes much faster. Some early implementors of client/server projects have experienced performance bottlenecks. And some application development tool vendors have rushed to exploit the situation by publishing performance benchmarks that show superiority in laboratory settings, which results are often too contrived to translate into real-world benefits.
With the release of SQLWindows Compiler, client/server developers now have the facility for clearing up a bottleneck by converting the slow 4GL code into fast 3GL code. Client/server projects are now more likely to meet end-user and management acceptance. And the laboratory results touted by some vendors as evidence of better performing 4GLs will lose all relevance given the order of magnitude greater performance that the SQLWindows Compiler will deliver.
Since a single language, the 4GL, was used to develop the application, the developer is not burdened with learning how to program in C. This is an important benefit since many people using 4GLs for client/server application development are either coming from a dBase or a mainframe COBOL backgrounds. To require them to learn C in addition to learning graphical and client/server technologies is onerous, especially because C is far less easy to learn than SQLWindows. Thus the SQLWindows Compiler builds upon existing SQLWindows skills to deliver performance with productivity.
Today, SQLWindows developers already have valuable facilities for enhancing application performance. These derive from a well-designed product architecture that includes features like early binding with optional late binding, use of array binding for networked database access, support for compiled SQL, and developer-controlled, in-memory caching of table windows.
Further, SQLWindows includes support for linking to dynamic link libraries (DLLs) written in a 3GL like C, C++ or COBOL. A DLL is simply a file which exists in compiled state and which is invoked by the main application at run-time to provide services. By writing code in 3GLs and interfacing it to SQLWindows code via function calls to the DLL, SQLWindows application performance is enhanced.
The SQLWindows Compiler enhances performance through generation of C DLLs; however, it eliminates the need to code these DLLs manually.
Using the SQLWindows Compiler to speed up your SQLWindows applications is easy:
When SQLWindows code is converted into C code, it is automatically converted into a DLL. The DLL is seamlessly linked with the SQLWindows application. The C DLL that is generated is fully functional and does not require the developer to change it. It includes support for communicating back with the SQLWindows code and interacting with local and remote databases.
An important issue for users of the SQLWindows Compiler is how to debug and maintain applications. The C code which is generated will work without additional modification or debugging in C. Since all debugging and maintenance is confined to the SQLWindows language level, application maintenance with the SQLWindows Compiler is as easy as maintaining regular SQLWindows applications.
The run-time structure of the accelerated application is essentially no different from the structure of DLL-enhanced SQLWindows applications today. The C code that has been generated resides in a DLL and is dynamically called at run-time, with the interaction being transparent to both the developer and end-user.
The SQLWindows Compiler is being delivered in two phases. The first phase will convert into C DLLs selected sections of SQLWindows applications. The second phase will include conversion of all application sections into C DLLs. In both cases, applications will benefit greatly from improved performance.
The performance benefit which will result from use of the SQLWindows Compiler depends upon the nature of the application. Applications that are CPU-bound will benefit more than applications that are disk-bound. For example, an application that does order entry imposes light CPU loads but heavy disk loads. But an application that does credit history verification is more CPU-bound and will therefore benefit more from this technology.
As in many other areas of computer science, the 80-20 rule applies. Often, about 20% of code is responsible for about 80% of the performance degradation. By carefully identifying which 20% is responsible for the performance lag, application performance can be significantly improved. For example, as shown in figure 7, let us assume a particular task requires 1000 lines of SQLWindows code and typically takes 10 seconds to complete. If the 80-20 rule applies, the first 800 lines require 2 seconds to complete, and the remaining 200 lines of code require 8 seconds to complete. Since C code can often run an order of magnitude faster than 4GL code, assume that the 200 lines of slow code can be converted into C and speeded up 10 times, i.e. they complete in 0.8 seconds, instead of 8 seconds. This results in a total completion time of 2 plus 0.8 = 2.8 seconds, which is over 350% faster.
For the first version of SQLWindows Compiler, let's assume an even more conservative example where only 100 of those 200 lines can be converted to C. In this case the performance will be 2 seconds for the first 800 lines, 4 seconds for the next 100 lines and 0.4 seconds for the last 100 lines, resulting in a total of 6.4 seconds, which is over 150% faster.
Even with simple "back of the envelope" arithmetic such as this, you can foresee the benefit this technology offers you. Of course, real world considerations like network traffic and varying workload and on the server will complicate performance measurements significantly. However, since the compiler is easy to use and does not destroy the code you originally wrote, it is easy to experiment with application performance by trying different approaches.
In speaking with early users of the current SQLWindows Compiler version, Gupta discovered that overall application performance was at least 20% faster in the worst case to 200 to 300% faster in the best case. We also discovered that typically about 15 to 30% of an can be converted to C. In some cases where careful structured programming practices are adopted, up to 50% of the application can be converted to C. Depending on the application's structure, performance improvements between 20 to 300% can be expected. Of course, due to the 80-20 rule, small alterations to the application structure can result in big performance benefits.
The next page documents results of tests performed. As you can see, compiled applications are much faster, in some instances 100 times faster. In these tests SQLWindows outperformed every other 4GL by a wide margin.
As we progress to higher levels of programming productivity with 4GLs, we are inclined to trade-off performance for productivity. Although this approach is satisfactory for small and simple applications, larger scale applications will find the performance penalty unreasonable. In the 1980s the software industry failed to bridge the performance gap between 4GLs and 3GLs. It is important for vendors to provide a facility that takes 4GL code and converts it into 3GL to deliver much higher performance.
Since Gupta's focus is on building large scale client/server applications, we attached great priority to being the industry pioneer with this technology. The current version of SQLWindows Compiler can enhance application performance. And a future version will deliver full compilation resulting in applications that are even faster.
The SQLWindows Compiler technology, together with other performance enhancing features of the product like array binding and early binding, ensures that SQLWindows applications will handily outperform other 4GLs in real-world situations. And together with other large scale programming facilities like a repository-driven team environment and complete object-orientation, Gupta offers unmatched support for large-scale application development.